Developed through the efforts of the ATM Forum and detailed in “The ATM Forum Technical Committee, Private Network-Network Interface Specification Version 1.0 (PNNI 1.0),” af-pnni-0055.000, Mar. 1996, PNNI 1.0 is a protocol standard that enables the building of multi-vendor, interoperable ATM switching networks. The protocol allows for the building and maintenance of large ATM networks because it provides hierarchical, dynamic link-state routing instructions and communication pathways. The protocol permits separate ATM switches within interconnecting networks to continuously communicate and share information. In addition, PNNI defines signaling requests for establishing and taking down point-to-point and point-to-multipoint connections across those networks.
PNNI routing is based on well-known, link-state routing techniques similar to, for example, Open Shortest Path First (OSPF). In addition to the basic link-state mechanism, PNNI provides support for quality of service (QoS) routing, required for applications with real-time requirements and scalability to large global networks. These features provide large-scale networks with a single routing protocol, unlike the Internet strategy of using a number of protocols at various levels.
To establish connections, PNNI environments operate with peer groups (PG), a collection of logical nodes that exchange information with other members of the group. This information exchange allows all members of the same peer group to maintain an identical view of the PG and for those nodes outside of the PG to exchange messages with the PG as a whole. In more detail, connections in PNNI networks are enabled through dynamic routing, which requires that each node exchange information (link state information) with other nodes in its peer group regarding the connection topology (links) between itself and the other peer nodes, as well as exchanging less-detailed information regarding the connection topology of nodes outside the peer group. This information exchange is done on a regular basis in order to keep the status of the links in the network updated. When a call setup request is received at an originating node, the originating node utilizes the information it has received in order to generate a stack of “Designated Transit Lists” (DTLs) for the routing of the call setup request through the network hierarchy. A DTL essentially comprises a string of node identifications that is sent in conjunction with the call setup request.
One of the difficulties with dynamic routing schemes is that it greatly complicates identification of failure points in the network. Failure points are also referred to as rejection points. Since the route for a particular connection cannot be predicted beforehand, it typically is necessary to use a trace mechanism to determine the actual route used. Although path and connection trace mechanism can identify the route being taken, it cannot be effectively used for troubleshooting, because the number of connection setup messages will overload the network due to the sheer size of the TTL (time to live) IE (information element).